--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>
> Currently M Codes only trigger code to execute in the DSP.  For example to execute a probe sequence with an option for the interpreter to re-sync to the new position before continuing on.  The DSP doesn't have access to the Interpreter internals such as the Tool Table.   There may be a way to meet your requirements just using GCode - something like set the global G92 A offset after the probe for example.  DSP code can swap the A and Z axis. So possibly setting the Knee to be the Z axis and then doing a Z move with the tool offset may work.  I don't fully understand what you are trying to do.  But if not, yes you are always free to modify KMotionCNC.  We recently added an Interpreter call back capability so an MCode can call back PC code which would then have access to all the Interpreter state so you can then basically do anything.  But his would involve re-compiling KMotionCNC with your code added every time you update to a new version. 
> Otherwise if it is something other users would benefit from we would want to incorporate the capability into KMotionCNC directly.
>
>
> The Pendent is all handled by the DSP.  The PC (Interpreter) just re-syncs to the current position when the GCode begins.
>
> Yes you are correct about the missing parenthesis.
>
> Regards
> TK
>
>
>
>
> ________________________________
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Sunday, October 23, 2011 3:14 PM
> Subject: [DynoMotion] Re: Some Questions About KFlop Capabilities....
>
>
>  
> Tom,
>
> OK, so sounds like the prompt on toolchange should be no problem, and everything else, if I'm understanding correctly, would involve modifying KMotionCNC as follows:
>
> 1) Probing to set work offset - create an M-code that invokes a DSP task to do the probe operation, and forces the A axis position (actually, even that is optional - the important part is moving the axis to the probe trigger position).
> 2) Toolcomp, using the knee - I'm assuming this would be a modification only to the tool offset code within KMotionCNC, to read the tool offset from the tool table, and move the A axis (knee) to the correct position. Or, as I do now, this function could me mapped to non-standard M-codes, so KMotionCNC would completely ignore them, other than passing them to the DSP. Does the DSP have access to the tool table?
> 3) Pendant - Would this be handled entirely in DSP code, or KMotionCNC?
> 4) External pushbutton controls - The PoKeys will map input events to Windows keypresses. I assume it would be relatively trivial to modify the KMotionCNC event handler to recognize those keypresses, and perform the appropriate operations?
>
> Do I have the above pretty much correct? If so, this isn't sounding too bad at all.
>
> This raises one question - are M-codes performed entirely by the DSP, KMotionCNC, or some combination of the two? Or (I suspect more likely) within the G-code interpreter DLL?
>
> BTW - Many/most of the examples in your KMotion Quick Reference appear to be borked - they're using the following construct:
>
> if (KM.WriteLine(0, "Move0=1000") MyError();
>
> which I believe *should* be:
>
> if (KM.WriteLine(0, "Move0=1000")) MyError();
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >
> > Ah, I missed that part.
> >
> > In KMotionCNC there is an option to throw up a MessageBox and pause using a special form of comment such as:
> >
> > (MSG,OK toContinue?)
> >
> >
> > G31 is not yet implemented.  Instead you could insert an M Code that would call a KFLOP User program to perform a probe operation and based on the result do something like set your A axis knee position or adjust Machine coordinates in some way. 
> >
> >
> > The MPG should be straightforward.
> >
> > We don't yet have a means for external inputs to trigger Keyboard events (other than hardware feedhold)
> >
> >
> > Regards
> > TK
> >
> >
> >
> >
> > ________________________________
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, October 23, 2011 12:27 PM
> > Subject: [DynoMotion] Re: Some Questions About KFlop Capabilities....
> >
> >
> >  
> > Tom,
> >
> > Sorry, I was obviously not clear in my post - my intent is to use KMotionCNC, NOT Mach3. For whatever reason, my machine configuration exacerbates several latent bugs in Mach3 and/or the SmoothStepper, and it's been making my life miserable for some time. I've been working with the Mach3 and SmoothStepper developers for months now, but as they cannot reliably duplicate the problems, progress is slow. I don't want to go through the pain of switching the KFLop, and end up right where I am now.
> >
> > As you point out, if I make a conversion cable (which is the plan), I should be able to easily go back and forth, but I want the option of divorcing myself from Mach3, and just want to understand better how much effort it will be to replicate my current functionality under KMotionCNC. Probably top priority would have to be getting prompts for toolchanges, and getting the knee working to apply tool length offsets, followed closely by having probing to set the A axis (knee) work offset, then getting the pendant working.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > It is likely to take some time to get everything switched over and configured per your requirements so you should probably make a conversion cable or something so you can easily switch back and forth if you run into any issue.
> > >  
> > > You mentioned in your earlier email about preferring C over VB but KFLOP C code is not really a replacement for Mach3 VB.  The difference is that the C routines have access to hardware deterministically in real time without any Windows, PC, or USB latencies.  So you might think of it closer to the Mach3 parallel port kernel driver functionality rather than Mach3 VB functionality.  Also the C code is running inside KFLOP not the PC so it does not have direct access to Mach3 variables and functions.
> > >  
> > > #1 - regarding G31 probing.  Yes it is supported and all your VB macros should work in the same manner as before.  The actual probe trigger, position capture, motion stop is performed in the KFLOP Notify.c program.  So you will need to modify that to monitor however your probe is wired in.  See:
> > >  
> > > http://dynomotion.com/Help/Mach3Plugin/Mach3Probe.htm
> > >  
> > > #2 - pauses and operator messages should probably be handled in the same manner you currently use
> > >  
> > > #3 - Z work offsets and such are again probably best handled using your current method.
> > >  
> > > #4 - Regarding PoKeys event inputs you can leave that as is or re-wire them to KFLOP inputs.   KFLOP has a total of 46 IO pins not a bazillion.  One exception is that KFLOP can do a hardware feedhold function so that input should be wired directly to KFLOP to avoid any Windows uncertainty.
> > >  
> > > #5 - Similarly with an MPG it should be wired directly to KFLOP and handled by a KFLOP C User program.  This allows it to have real-time response.  See the Init programs that also loop servicing the MPG such as Init3AnalogPlusMPG.c
> > >  
> > > Hope this addresses some of your concerns.
> > > Regards
> > > TK
> > >  
> > >  
> > >  
> > >  
> > >
> > >
> > > ________________________________
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Sunday, October 23, 2011 6:08 AM
> > > Subject: [DynoMotion] Some Questions About KFlop Capabilities....
> > >
> > >
> > >  
> > > I'm getting really close to springing for a KFlop, but it's critical the switchover from Mach3/SmoothStepper be as quick and painless as possible, so I want to make sure I understand how to do it, and that there will be no surprises on critical capabilities. So, here goes:
> > >
> > > 1) I assume KFlop supports G31. I have a large assortment of Mach3 probing macros I wrote for doing things like locating corners, finding the center of a circular pocket or post, setting tool offsets, etc. I assume all of this can be easily duplicated as C programs runnning on KFlop?
> > > 2) I do not have a toolchanger, so I need the program to pause for toolchanges, and prompt me to change the tool. I assume KFlop can do this?
> > > 3) My machine (a knee mill) uses the knee to apply tool length compensation, so I always have full quill travel as my Z axis. In Mach3, I did this through custom macros (M843, M849) that take the place of G43 and G49. KFlop appears to have the ability to define user M-codes, as C-programs, so duplicating my tool offset macros should be fairly straight-forward, right?
> > > 4) I have a control panel, with about a bazillion buttons on it, as my primary control panel. This is interfaced to Mach3 through a PoKeys. How can this be interfaced to a KFlop?
> > > 5) I have a pendant that can be interfaced through about 10 digital inputs, on a parallel port, SmoothStepper, or Modbus, and uses a Mach3 macropump as the driver. How could this be interfaced to KFlop?
> > >
> > > Thanks!
> > >
> > > Regards,
> > > Ray L.
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> I'm getting really close to springing for a KFlop, but it's critical the switchover from Mach3/SmoothStepper be as quick and painless as possible, so I want to make sure I understand how to do it, and that there will be no surprises on critical capabilities. So, here goes:
>
> 1) I assume KFlop supports G31. I have a large assortment of Mach3 probing macros I wrote for doing things like locating corners, finding the center of a circular pocket or post, setting tool offsets, etc. I assume all of this can be easily duplicated as C programs runnning on KFlop?
> 2) I do not have a toolchanger, so I need the program to pause for toolchanges, and prompt me to change the tool. I assume KFlop can do this?
> 3) My machine (a knee mill) uses the knee to apply tool length compensation, so I always have full quill travel as my Z axis. In Mach3, I did this through custom macros (M843, M849) that take the place of G43 and G49. KFlop appears to have the ability to define user M-codes, as C-programs, so duplicating my tool offset macros should be fairly straight-forward, right?
> 4) I have a control panel, with about a bazillion buttons on it, as my primary control panel. This is interfaced to Mach3 through a PoKeys. How can this be interfaced to a KFlop?
> 5) I have a pendant that can be interfaced through about 10 digital inputs, on a parallel port, SmoothStepper, or Modbus, and uses a Mach3 macropump as the driver. How could this be interfaced to KFlop?
>
> Thanks!
>
> Regards,
> Ray L.
>